Project information providing system and project information providing method

ABSTRACT

By managing and providing information such as know-how from a product using registration of the product as a trigger, it is possible to rapidly and effectively provide information on a project product. As a result, for example, it is possible to provide timely service utilizing this information.

TECHNICAL FIELD

The present invention relates to a project information providing systemproviding information (for example, know-how) related to a project.

BACKGROUND ART

The progress of a project is registered in a project management system.Here, the project means, for example, a development project developing apredetermined program and so forth. The progress and products (aspecification, a program itself as a final result and so forth) of theproject are registered in the project management system to becomeavailable for a person in charge of the project (project member) torefer.

In order to accomplish a project, a variety of information is required.In that case, the required information can be acquired by searchingproducts of the other project using the project management system.

The acquisition of the project-related information is usable not onlyfor developing in the project, but also for providing information orservices to clients.

As to the project information acquisition, there are disclosed arts asdescribed below.

In Japanese Patent Laid-Open Application No. Hei 9-16392, there isdisclosed a software development support system enabling to acquirerelevant products easily when making a modification to a certainproduct, in which an association is established between each of everyproduct.

In Japanese Patent Laid-Open Application No. Hei 8-137901, there isdisclosed a product information management device capable of managingproduct information up to the completion of a project appropriately, inwhich product information is collected and registered when the productinformation is inputted and a key information of the project is changedwhen the completion of the project is detected.

DISCLOSURE OF THE INVENTION

In order to acquire project information in conventional systems, aperson who requires the information has to search the project registeredin the project management system. In other words, the search of theproject information is not performed until the person being a receiverof the information feels a need of the information.

Meanwhile, the required information is not always well-defined in thecourse of the project in a lot of cases. When the required informationis clearly defined, frequently, a problem is already apparent (forinstance, a case where a problem arose when running a program.) Aproblem solving possibly takes a lot of time when searching a solutionafter the problem arose.

Also, when providing information or a service to a customer, it is notalways easy to provide information contents being appropriate for eachcustomer. For a service provider providing services to customers, aprovision of a service being appropriate for each customer requires toknow well about the customer's information to always search theinformation for the customer's information for the customercontinuously. This is an overload operation for the service provider.

However, when information is provided at random, the customer being aninformation receiver has to select information that the customeractually wants. This means that, even when there is informationeffectively usable, the costumer has to select the information he/shewants from among a large amount of information. When the customer wantsto use the electively-usable information while it is very fresh, thecustomer has to repeat to search again and again, possibly leading to ahigher cost.

The present invention has been made in consideration of the viewpointsdescribed above, and an object thereof is to provide a projectinformation providing system providing information on a project productrapidly and effectively.

A. The project information providing system according to the presentinvention is characterized in that the project information providingsystem includes: a product registration unit registering a product of aproject; an information management unit managing information containedin the product using the registration of the product by the productregistration unit as a trigger; and an information providing unitselecting and providing information contained in the product using theregistration of the product by the product registration unit as atrigger.

By performing management and provision of information contained in aproduct such as know-how using the registration of the product as atrigger, it is possible to rapidly accumulate and provide theinformation such as know-how. As a result, for example, it is possibleto provide timely service utilizing this information.

By preparing a table to provide information, it is possible to rapidlyselect and provide information. For instance, by setting a criterion forselecting information for each customer (service receiver), it ispossible to timely provide information to the customer.

This table can be realized as a know-how map when the information isknow-how. Note that the table may be divided into that for managementand that for provision, whereas a single integrated table causes noproblem.

(1) The table may record information enabling to refer to contentsrecorded in the other table.

By referring to the other table related to a certain table, more variousinformation can be selected to be provided.

In that case, when the table is in a hierarchical relation with theother table, there arises no problem.

For instance, by performing a hierarchical management of the table fromeach project level to an organization or entire company level, it ispossible to register and provide information by classifying theinformation into those specific to a project having limited scope ofapplication but having high added-value and those with relatively smalleffect of application but is commonly usable.

(2) The table may record information indicating priorities for theinformation selection and provision.

By giving priorities, it is possible to easily determine usability ofinformation, so that the burden on information selection can be reduced.

B. The project information providing method according to the presentinvention is characterized in that the information providing methodincludes: a step of product registration registering a product of aproject; a step of information management managing information containedin the product using the registration of the product in the productregistration step as a trigger; and a step of information provisionselecting and providing information managed in the informationmanagement step.

By performing the selection and provision of information such asknow-how from a product using the registration of the product as atrigger, it is possible to rapidly accumulate and provide theinformation such as know-how.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram showing a configuration of a projectinformation providing system according to an embodiment of the presentinvention.

FIGS. 2A and 2B are diagrams schematically showing an outline of aknow-how provision in the project information providing system accordingto the embodiment of the present invention and that in a conventionalsystem, respectively.

FIG. 3 is a conceptual view showing an example product to be registeredin a product DB by a product registration unit.

FIG. 4 is a schematic diagram showing an example know-how map.

FIG. 5 is a schematic diagram showing a hierarchical structure(management pattern) of the know-how map.

FIG. 6 is a schematic diagram showing a relation between a product and aknow-how contained in the product in the case where the product is atest specification and a test report.

FIGS. 7A and 7B are schematic diagrams showing an example know-how map.

FIGS. 8A to 8C are schematic diagrams showing an example know-how mapfor provision and example know-how maps for management related thereto.

FIG. 9 is a flowchart showing an outline of operating procedures of theproject information providing system.

FIG. 10 is a flowchart showing procedures of a detailed updateprocessing of the know-how map by a know-how map updating unit.

FIG. 11 is a flowchart showing procedures such as a know-how selectionby a know-how map reference unit.

BEST MODE FOR IMPLEMENTING THE INVENTION

Hereinafter, a mode according to the present invention will be describedin detail with reference to the drawings.

FIG. 1 is a block diagram showing a configuration of a projectinformation providing system 10 according to the mode of the presentinvention.

As shown in FIG. 1, the project information providing system 10 iscomposed of a project management system 20 and a knowledge-based system30, and a product database (DB) 40, a know-how map database (DB) 50 anda know-how database (DB) 60 connected thereto.

Note that the project information providing system 10 is segmented intothe project management system 20 and the knowledge-based system 30 forthe purpose of convenience, so that the project information providingsystem 10 may be realized as a single system.

The project management system 20 is to manage a project itself andproducts of the project, and includes a product registration unit 21 anda product search unit 22.

The knowledge-based system 30 is to manage know-how (usable technicalknowledge related to the project), and includes a know-how mapregistration unit 31, a know-how map updating unit 32, a know-how mapreference unit 33, and a know-how providing unit 34.

The product DB 40, know-how map DB 50 and know-how DB 60 are storagedevices storing a product, a know-how map and a know-how, respectively.

The product means every product generated in the course of accomplishingthe project such as a specification (for example, a programspecification defining the specification of a program, a testspecification defining the specification of a program test), a report (atest report recording the test result of a program), a program itselfproduced in the project and so forth. Note that the details and aspecific example of the product will be described later.

The know-how map is the information to manage know-how form pluralviewpoints. The know-how maps are divided into two types, namely aknow-how map for management to manage know-how contained in the productand a know-how map for provision to provide the know-how. Note that thedetails of the know-how map will be described later.

The product registration unit 21 accepts a registration request for aproduct to register the product in the product DB 40. The productregistration unit 21 boots the know-how map updating unit 32 andknow-how map reference unit 33 when registering the product in theproduct DB 40. As a result, the management, selection and provision ofthe know-how are performed at the time of the product registration as atrigger (event or stimulus). Note that the booting of the know-how mapupdating unit 32 and know-how map reference unit 33 is not necessarycarried out together with the product registration. There is no problemwhen the bootings of the know-how map updating unit 32 and know-how mapreference unit 33 are carried out a certain time after the productregistration.

The product search unit 22 searches over the products registered in theproduct DB 40 to select a desired product. This search is performedbased on a keyword, a project management number, a product managementnumber or the like accepted by the product search unit 22.

The know-how map registration unit 31 accepts a know-how mapregistration request to acquire a necessary know-how from a product toregister the know-how map in the know-how map DB 50.

The know-how map updating unit 32 updates the know-how maps registeredin the know-how map DB 50 in response to an instruction from the productregistration unit 21. Specifically, the know-how map is updated inaccordance with a condition recorded in the know-how map for managementand the know-how contained in the registered product.

The know-how map reference unit 33 refers to the know-how map forprovision registered in the know-how map DB 50 in response to theinstruction from the product registration unit 21. Then, the provisionconditions to provide the know-how contained in the product areretrieved. Further, the information to identify the know-how managed ina (later-described) relevant know-how map related to the updatedknow-how map is retrieved. The know-how map reference unit 33 deliversthese provision conditions and so forth to the know-how providing unit34 to let the know-how providing unit 34 perform a selection, provisionand so forth of the know-how.

The know-how providing unit 34 selects required product and know-howfrom the product DB 40 and the know-how DB 60 based on the know-how mapfor provision, sets priorities and provides them. This provision iscarried out, for example, by storing the know-how in a storage device ofa computer of a person desiring to be provided via a network. Note thatthe provision destination can be recorded in the know-how map forprovision.

In the present mode, the update of the know-how map in the know-how mapDB 50 is performed by the know-how map updating unit 32 using theregistration of the product by the product registration unit 21 as atrigger. Also, using this product registration as a trigger, thereference unit 33 refers to the know-how map for provision, andfurthermore the know-how providing unit 34 selects and provides theknow-how.

When the person who is provided with the know-how is a member of someproject, he/she can acquire relevant know-how previously in accordancewith the progress of the project, so that the project can be processedeffectively. Moreover, when the entity which is provided with theknow-how is a service provider, the provider can prepare in advance theknow-how usable for a customer service.

FIG. 2 are views showing an outline of a know-how provision in theproject information providing system 10 and that in a conventionalsystem by comparison. FIGS. 2A and 2B show the outline in a conventionalsystem 100 and that in the project information providing system 10according to the present mode, respectively.

As shown in FIG. 2A, the conventional system 100 is configured to have aproject management system 120 and a knowledge-based system 130, as anindependent system, respectively. The project management system 120 is asystem managing the progress and products of the project, in which thoseproducts generated along with the progress of the project are managed.The knowledge-based system 130 manages know-how separately from theproject management system 120.

On the other hand, in the project information providing system 10, themanagement and provision of the know-how are performed using theregistration of a product as a trigger, on the basis of an interlockedoperation of the project management system 20 and the knowledge-basedsystem 30. Accordingly, the know-how storage and provision are performedrapidly.

FIG. 3 is a conceptual view showing an example of the products to beregistered in the product DB 40 by the product registration unit 21.

The project management system 20 manages products in a project. When theproduct is registered in the product DB 40, product information beinginformation to manage the product is generated. The product informationincludes information related to the property and location of theproduct.

As “product information”, there are a “development project” (a projectidentification information such as a project management number of theproject related to the product, or the “development project information”itself), a “product name”, a “product management number” (a kind of theproduct identification information identifying the product from eachother, the number being a unique management number in the projectinformation providing system 10), a “product classification number” (aclassification showing the type of the product), and a “product locationnumber” (information showing the location of the product itself), asexamples.

As “development project information”, there are a “project name”, a“project management number” (a kind of the project identificationinformation identifying the project from each other, the number being aunique management number in the project information providing system10), a “customer information” (information related to the destination ofthe system developed and provided by the project), a “progressinformation” (information related to the progress of the project), and a“product information”, as examples. Specifically, here, the “developmentproject information” includes the “product information”. Note thatinformation (for example, the product management number) indicating acorresponding relation of the project and the product may be included inthe development project information instead of the “productinformation”.

The project may be stored (managed) in the project information providingsystem 10 itself or in anywhere other than the project informationproviding system 10. When the project information providing system 10manages the product, the product location information can be representedby a pass showing the directory where the product file is stored or anURL (UNIFORM Resource Locator). Meanwhile, when the product is managedas a paper document (paper-based), the product location information canbe represented by the name of the administrating department, the name ofthe responsible person, an e-mail address or a telephone number.

Subsequently, the description will be given of the details of theknow-how map. The know-how map is information to manage the know-how.The know-how map is divided into two types, namely the know-how map formanagement being a criterion in managing the know-how contained in theproduct and the know-how map for provision being a criterion inproviding the know-how.

FIG. 4 is a schematic diagram showing an example know-how map formanagement. In this example, the know-hows are managed by beingclassified by a combined two elements (criteria for managing theknow-how) of “development process” and “technical field”. Further, a“relevant know-how map” related to the know-how map for management islinked to the know-how map for management.

In the case of the program development, the “development process” can beclassified into a program design (decision on program specification orthe like), a program production and a program test. Note that theprogram development is frequently conducted by being classified intomodules, so that the design, production and test can be furthersegmented into the designs, productions and tests of the module level.

The “technical field” can be classified on the basis of the programdetails such as a database, image processing, communication, POS(point-of sale) and so forth, as examples.

In the know-how map for management shown in FIG. 4, for the productcontaining know-hows, plural development processes and technical fieldsare designated, respectively, so that the product is managed by thecontained know-hows corresponding to the designated developmentprocesses and technical fields.

The know-how map for management shown in FIG. 4 is a two-dimensional maphaving a combinatorial structure composed of two elements, however, theknow-how map maybe a three or more dimensional map classified into threeor more elements.

As elements thereof, other than the above, a language used fordevelopment (C++, Java (registered trademark) and soon), a system sizeinvolving the program to be developed (a standalone (a single computer),a small-sized network or a large-sized network) and so forth can beconsidered.

As a “relevant know-how map”, a know-how map of a higher level or alower level with respect to the know-how map for management, and aknow-how map of a relevant project can be considered.

FIG. 5 is a schematic diagram showing a hierarchical structure(management pattern) of the know-how map.

The know-how map in FIG. 5 is segmented into a superior position, amiddle position and a subordinate position by a “project” for eachproject, an “industry/business” for each industry/business and a“common” being common for every project. Specifically, an “industry 1”positions superior to a “PJ-A” and a “PJ-B”; a “business 1” positionssuperior to a “PJ-C” and a “PJ-D”; and a “common” positions superior tothe “industry 1” and “business 1”. In short, the higher the element forthe know-how management positions, the more generic concept the elementhas.

In the subordinate position of the know-how map, individual and specificknow-hows are managed; and in the superior position thereof, genericknow-hows are managed. Generally, the more specific the know-how is, thehigher is the application effect, while the applicable scope tends to besmaller. On the other hand, when the know-how is made to be common tobroaden the applicable scope, the effect itself tends to be smaller. Theknow-how map performs a hierarchical management in accordance with theapplicable scope. Specifically, in the subordinate level of the know-howmap, the know-hows with a smaller applicable scope but with a highadded-value if applied, and in the superior level thereof, the know-howswith a large applicable scope are managed.

The know-hows to be stored are in a relation in which the part commonwith the subordinate know-how map is escalated to the know-how map beingsuperior thereto. Thus, with the combinational use of the superior andsubordinate know-how maps, a combinational use of the know-how with alarge applicable scope and that with a high effect is possible.

By registering know-how maps, which are superior and subordinate to aknow-how map for management, in the relevant know-how map shown in theknow-how map for management in FIG. 4, the hierarchical use of theknow-how maps is enabled.

For instance, in the case where the know-how map for management is the“industry 1” shown in FIG. 5, the subordinate “PJ-A” and “PJ-B” areregistered as the relevant know-how maps. As a result, it is possible torefer to more specific know-how from the subordinate know-how maps.Further, by referring to the superior “common” know-how map as therelevant know-how map, it is possible to refer to the know-how beingusable in common over a company. Further, in the case where the know-howmap for management is the “PJ-B”, by registering “PJ-A” and “PJ-D”,which are related to project(s) being similar to the “PJ-B”, as therelevant know-how maps, the “PJ-A” and “PJ-D” can be referred to inaddition to the “PJ-B”.

By giving priorities to the relevant know-how maps, it is possible tohandle them in accordance with their priorities. For instance, in thecase where the know-how map for management is the “PJ-B”, by definingthe know-how map “PJ-A” of the relevant project as priority 1 and thesuperior know-how map “industry 1” as priority 2, the know-howscontained in the product can be classified in accordance with theirpriorities. With the priorities, it is possible to confirm the know-howsin order from those of higher priorities or to eliminate those of lowerpriorities, when receiving the know-hows.

As described above, the description has been given to the know-how mapfor management, whereas the same is also realizable in the know-how mapfor provision in the same manner.

Here, it is also possible to integrate the know-how map for managementand the know-how map for provision into a single know-how map, so thatthe registration and provision of the know-how can be performed in thesame know-how map. For instance, when the know-how map is of a certainproject, and the person to receive the know-how is a member of theproject, the integration of the know-how maps raises no problem. Byintegrating the know-how map for management and the know-how map forprovision, both the know-how maps can be updated at once, so that anefficient update of the know-how maps can be enabled.

FIG. 6 is a schematic diagram showing a relation between the product andthe know-hows contained in the product in the case where the product isthe test specification and the test report. The test specification is aproduct in the prior stage to the test process and the test report is aproduct at the completion of the test process. These products containitems such as a “test policy” (the criteria for the test conducted), a“test outline” (global image of the test), “test item(s)” (actual testitem(s) conducted), a “test result” (where problem arose), a “countermeasure” (countermeasure against problem)

The product contains know-hows.

For instance, the “test policy” contains a generic know-how about thetest “a philosophy to determine test items” that can be used as a baseof the test environment or test coverage level in a similar system.

The “test items” contain a know-how specific to the test “Is there anyreusable test item?”, in which the test items themselves can be divertedin the system exhibiting a higher similarity. This is not limited onlyto the test items, and when the test program can be diverted,substantial laborsaving effect can be obtained.

The “test result” contains know-how related to design and production“points to be cautious in designing and production”. For instance, thepoint tends to be rejected in a test, namely the point to be cautious inthe design and production can be confirmed.

The “countermeasure” contains specific know-how to ensure quality “Howto avoid or solve a problem?” in which a modification to the rejectedtest item possibly becomes a reference when coping with a trouble.

FIG. 7 show example know-how maps. Here, the product is assumed to be atest specification and test report as in the case of FIG. 6.

FIG. 7A and FIG. 7B are views showing a know-how map MP1 at a certainhierarchical level and a know-how map MP2 at a superior level thereto,respectively. The know-how maps MP1 and MP2 are updated at everyregistration of products so as to correspond to the know-how containedin the products.

The product is registered first to a subordinate know-how map (FIG. 7A)in accordance with the know-how contained therein. This know-how map isclassified into individual technologies A, B, C.

Also, the product is categorized based on the superior concept using thesuperior know-how map (FIG. 7B). Here, the product is classified intoelements of “overall management” and “load test”.

FIGS. 8A to 8C are schematic diagrams showing examples of a know-how mapfor provision MP0 (ZERO), and the know-how maps for management MP1, MP2related thereto, respectively. In the examples, the know-how map forprovision MP0 (ZERO) refers to the know-how maps for management MP1,MP2. As a result, the know-how map for provision MP0 (ZERO) and theknow-how maps for management MP1, MP2 can be used for selecting know-howfor provision.

The know-how maps MP1, MP2 are assumed to be the same as the know-howmaps MP1, MP2 shown in FIGS. 7A and 7B.

Note that the know-how map for provision MP0 (zero) is not necessarilyhave the same form as of the know-how maps for management MP1, MP2;whereas in the present example, the know-how map for provision MP0(zero) is assumed to have the same form as of the know-how maps formanagement MP1, MP2 in view of the structure segmented by two-dimensionsof “development process” and “technical field”.

The case, in which priorities are given to the know-hows selected by theknow-how maps for management MP1, MP2, will be shown.

As an example, priorities are given in the following manner.

(1) Priority 1: out of the know-hows in the subordinate know-how map formanagement MP1, those know-hows of which both the development process(“production process” and “test process”) and technical field(“technology A” and “technology B”) are the same as of the know-how mapfor provision (area 1).

(2) Priority 2: out of the know-hows in the superior know-how map formanagement MP2, those know-hows of which both the development processand technical field are the same as of the know-how map for provision(area 3).

(3) Priority 3: out of the know-hows in the subordinate know-how map formanagement MP1, those know-hows of which both the development processand technical field are the same as of the know-how map for provision(“overall management” is assumed to include “technology A” and“technology B”) or those know-hows including the same (area 2 a, 2 b, 2c).

(4) Priority 4: out of the know-hows in the superior know-how map formanagement MP2, those know-hows of which both the development processand technical field are the same as of the know-how map for provision orthose know-hows including the same (area 4 a, 4 b, 4 c).

Subsequently, the description will be given of a utilization method ofthe know-how maps.

By referring to the subordinate know-how map for management MP1, it ispossible to refer to the know-hows related to the production, testprocess and technologies A, B in the know-how map MP1. Here, it is foundthat, from the test result of the test specification, those know-hows inthe production process and related to the technology A as well as, fromthe test items of the test specification, those in the test process andrelated to technology B are available.

When necessary information cannot be obtained in the subordinateknow-how map for management MP1, it is possible to refer to the commonlyusable know-hows related to the production, test process and overallmanagement by referring to the superior know-how map for management MP2.From the test policy of the test specification, it is possible to referto know-how in the test process and related to the overall management.

In this manner, by classifying the know-hows in accordance with theirpriorities, it is possible to know the coverage of the required know-howas a reference.

(Operation of the Project Information Providing System 10)

FIG. 9 is a flowchart showing an outline of operating procedures of theproject information providing system 10. The operating procedures of theproject information providing system 10 will be described with referenceto the drawing.

(1) Product Registration (Step 10)

Along with the progress of a project, a project member registers aproduct using the product registration unit 21. As a result, theinformation of the product itself is registered in the product DB 40,for example, in the form as shown in FIG. 3.

At the time of the product registration, as required, the informationindicating the progress of the project, for example, the specific statusof the development process over the designing, production and test, isinputted. Note that the know-how map used here is the one previouslyregistered by the know-how map registration unit 31.

(2) Know-How Registration (Step 20)

The product registration unit 21 registers products, and at the sametime, gives an instruction to the know-how map updating unit 32 toupdate the know-how map. As a result, the know-how map for management isupdated using the acceptance of the product registration as a trigger.For instance, the know-how map in FIG. 4 managed in a hierarchicalmanner as shown in FIG. 5 is updated to be those in FIGS. 7A and 7B.

FIG. 10 is a flowchart showing detail procedures of the know-how mapupdating processing by the know-how map updating unit 32. Hereinafter,the description will be given based on FIG. 10.

Corresponding to the know-how contained in the product, the product isshown in the know-how map for management (Step 21). Specifically, theproduct location information, the product keyword and the like arerecorded in the know-how map.

As required, the relevant know-how map related to the know-how map formanagement is changed (Step 22).

In response to the update of the know-how map, a collation is performedwith the relevant know-how map to establish an association with theknow-how map of which know-how can be diverted most easily. Note thatthis association change can be performed by referring to a table or thelike in which a change condition was recorded.

When the product registration is performed as described above, theknow-how thereof is managed by being indicated in the know-how map suchthat the know-how belongs to which development process and technicalfield. It is possible to indicate the know-how in the form of embeddingin the know-how map table, so that the know-how that the project holdsor does not hold becomes visible.

(3) Know-How Provision (Step 30)

The product registration unit 21 gives an instruction to boot theknow-how map reference unit 33 at the same time of booting the know-howmap updating unit 32. As a result, a know-how provision is performedusing a product registration as a trigger.

FIG. 11 is a flowchart showing the procedures of the know-how provisionperformed by the know-how map reference unit 33. Hereinafter, thedescription will be given based on FIG. 11.

a. the know-how map reference unit 33 refers to the know-how map forprovision (Step S31), and sets a search criterion to thereby issue asearch request for know-how to the know-how providing unit 34 (StepS32).

b. the know-how providing unit 34 accepted the request searches know-howfrom the product DB 40 and know-how DB 60 based on the search criterionto determine whether or not the search satisfying the predeterminedcriterion is possible (Step S33).

The predetermined criterion is, for example, the upper limit or lowerlimit of the number of pieces to search. Further, by combining thenumber with the search criterion, it is possible to set the upper orlower number to search for each single search criterion or for acombined plural search criteria. Further, the priorities can be set tothe predetermined criteria. For instance, the search result of thecombined plural criteria (technical field and development process) canbe prioritized rather than the search result of a single criterion(technical field or development process).

When the search cannot satisfy the predetermined criterion, the searchis performed again using the relevant know-how map (Step S34). Note thatthe relevant know-how map may be given the priorities and the search maybe performed in the order from the highest priority.

The provision of searched out know-how is performed (Step S35).

This know-how provision can be realized by any of the provision of theproducts accumulated in the product DB 40 or the provision of theknow-hows accumulated in the know-how DB 60. The reason is that theprovision of the product also means the provision of the know-howcontained therein.

At that time, with the weight of the search criterion, it is possible toprovide know-how in accordance with the priorities from highlyapplicable know-how to further generic know-how.

As described above, it is possible to provide information in accordancewith the status of the service receiver by weighting on informationseemed to be required.

In the project information providing system 10 described above, theknow-how map for management and the know-how map for provision can beused differently. For instance, by comparing the know-how map forprovision registered in advance in accordance with customer requirementsand the updated know-how map for management as in FIG. 8, it is possibleto provide know-how to a system user such as the service provider bysetting priorities in accordance with the customer requirement. Theservice provider acquires the know-how that is prioritized in accordancewith the customer requirement as needed, so that the service providercan provide high-quality services backed by know-how to customers.

Meanwhile, the know-how map for provision and the know-how map formanagement can be integrated to be used in common. This is appropriatein the case of feeding back the provided know-how directly to adevelopment project member.

Additionally, with this integration of the know-how map for managementand the know-how map for provision, the productivity of the developmentproject can be increased on the back of a further simplified system.Specifically, with the integration of schemata of the know-how maps aswell as the know-how maps themselves, the know-how to efficiently carryout the subsequent development process can be acquired in response tothe product registration of each single development process.

INDUSTRIAL APPLICABILITY

The project information providing system and the project informationproviding method according to the present invention enables a rapid andefficient provision of information on a project product, and can beproduced and implemented from an industrial point of view.

1. A project information providing system, comprising: a productregistration unit registering a product of a project; an informationmanagement unit managing information contained in the product using theregistration of the product by said product registration unit as atrigger; and an information providing unit selecting and providinginformation contained in the product using the registration of theproduct by said product registration unit as a trigger.
 2. The projectinformation providing system as set forth in claim 1, wherein theinformation managed by said information management unit is classifiedbased on a predetermined table.
 3. The project information providingsystem as set forth in claim 1, wherein the table records informationenabling to refer to a content recorded in other table.
 4. The projectinformation providing system as set forth in claim 3, wherein the tablehas a hierarchical relation with the other table.
 5. The projectinformation providing system as set forth in claim 1, wherein the tablerecords information indicating priorities used to select or provideinformation.
 6. A project information providing method, comprising: astep of product registration registering a product of a project; a stepof information management managing information contained in the productusing the registration of the product in said product registration stepas a trigger; and a step of information provision selecting andproviding information managed in said information management step.